Uno de los controles estrella que incorporó la versión 4.0 de PCI DSS fue la protección contra ataques de e-skimming a través de los requisitos 6.4.3 y 11.6.1. Este control fue la respuesta del PCI SSC ante la masificación de este tipo de ataques en años anteriores. En este artículo se describirán las distintas alternativas técnicas para implementarlo.
Introducción
En junio de 2008, Ticketmaster sufrió un incidente de seguridad que afectó a cerca de 40.000 clientes incluyendo nombres, direcciones, correos electrónicos, números telefónicos y detalles de pago, incluyendo datos de tarjetas. Dicho incidente tuvo origen en un proveedor de servicios de chatbot (Inbenta Technologies) que había sido comprometido previamente. Debido a que los componentes de este servicio de chatbot eran cargados de forma camuflada en las páginas de captura de datos de tarjetas cuando se realizaban pagos, los delincuentes pudieron capturar y exfiltrar esta información sensible sin ser detectados durante varios meses.
Ataques similares fueron identificados en las páginas de comercio electrónico de British Airways, Hanna Anderson, Snowflake y muchos otros sitios web que, en su mayoría, ejecutaban versiones vulnerables de Magento.
Copia de las 22 líneas de código que se inyectaron en el sitio web de British Airways para exfiltrar información confidencial
Todos estos ataques tenían un patrón de operación similar:
- Ataque a sitios web de comercio electrónico con tráfico masivo pertenecientes a empresas muy reconocidas.
- Uso de automatización para optimizar los tiempos de infección en sitios vulnerables.
- Utilización de técnicas de inyección de código y técnicas de ofuscación para crear formularios de pago falsos o modificar la lógica en la captura y envío de datos en formularios existentes, en donde la operación normal del sitio afectado no se ve comprometida, con el fin de garantizar persistencia al delincuente.
- Activación de tareas de reinfección para no perder el control de los sitios comprometidos.
- Ataques a proveedores de servicios y componentes externos (como librerías, código JavaScript, etc.) para comprometerlos y, posteriormente, cargar los componentes comprometidos en los sitios web de sus clientes (supply chain attacks).
- El foco de los ataques se encontraba en los datos de tarjetas de pago.
Debido a la similaridad en su operación con los ataques de skimming físico (en donde los delincuentes manipulan las interfaces de lectura de datos de tarjetas físicas de cajeros electrónicos y terminales de pago para leer y copiar la información de la banda magnética o del chip de una tarjeta), estos ataques se denominaron e-skimming, digital skimming, web skimming o formjacking, ataques del lado del cliente (client-side attacks) en donde los atacantes inyectan código malicioso en sitios web de comercio electrónico para comprometer información confidencial (típicamente datos de tarjetas) ingresada por los usuarios en las páginas de pago (checkout) u otros formularios en línea sin que el usuario afectado sea consciente del ataque.
Los ciberdelincuentes que usaban estas técnicas (activos desde 2014) se catalogaron bajo la marca “MageCart”, ya que muchos de sus ataques fueron dirigidos hacia plataformas vulnerables de comercio electrónico que ejecutaban Magento.
Con el fin de protegerse de dichos ataques, se recomienda la implementación de las siguientes medidas:
- Identificar todos los componentes activos (JavaScript y ActiveX) que se ejecuten en el sitio web.
- Establecer relaciones de confianza con los proveedores de componentes activos.
- Hasta donde fuera posible, ejecutar las instancias de componentes activos de forma local en vez de invocarlas remotamente.
- Implementar encabezados HTTP Content-Security-Policy (CSP), que ofrecen una capa adicional de protección contra ataques de cross-site scripting (XSS), clickjacking y otros ataques de inyección de código.
- Mantener actualizados el software base y todas las librerías y componentes que hacen parte de un sitio de comercio electrónico.
Enfoque de PCI DSS: Requisitos 6.4.3 y 11.6.1
PCI DSS version 4.0 incorporó dos requisitos parta la protección de ataques de e-skimming:
Requisito 6.4.3:
- Implementar un método para confirmar que cada script cargado y ejecutado en el navegador del cliente está autorizado.
- Asegurar la integridad de cada script.
- Mantener un inventario de todos los scripts junto con su justificación de uso por escrito, ya sea por razones técnicas o de negocio.
Este requisito se aplica a todos los scripts cargados desde el entorno de la entidad y a los scripts cargados desde terceras y cuartas partes.
Requisito 11.6.1:
Desplegar un mecanismo de detección de cambios y de manipulación para:
- Alertar al personal si se detectan modificaciones no autorizadas de
- Encabezados de seguridad (HTTP headers) con impacto en la seguridad
- Contenido de scripts recibidos por el navegador del usuario durante el proceso de pago
- Dichos mecanismos deben estar configurados para evaluar los encabezados HTTP y las páginas de pago.
- Estas funciones deben ejecutarse de forma semanal o periódica (la entidad puede definir la frecuencia a través de un análisis de riesgos focalizado).
Estos controles son obligatorios a partir del 1 de abril de 2025.
Opciones de implementación
A pesar de que no se exige la implementación de una solución en particular, en términos técnicos se pueden implementar estos controles a través de cuatro (4) enfoques distintos:
Opción 2: Monitorización web sin agente (agentless)
Este tipo de soluciones, también llamadas sin agente (agentless) o synthetic users (bots) suelen emular las interacciones del navegador web de un usuario y analizar todo el contenido que ha sido provisto desde una página web en particular.
| Ventajas | Desventajas |
|---|---|
| No requiere ningún cambio en el sitio web a monitorizar | Su ejecución suele ser programada, de tal manera que se pueden presentar ventanas de tiempo en las que el contenido malicioso puede no ser detectado. |
| Puede monitorizar todo el flujo operativo de una sesión, como si se tratara de un usuario real | Su ejecución es más lenta, ya que consume más recursos |
| Su forma de trabajar es detectiva, no tiene forma de ejecutar acciones correctivas ante la detección de comportamiento malicioso. |
Ejemplos de soluciones que implementan este enfoque:
- RapidSpike: https://www.rapidspike.com/magecart-attack-detection/
- Reflectiz: https://www.reflectiz.com (aunque también implementa funcionalidades de proxy, como se verá más adelante).
Opción 3: Monitorización web con agente
En la monitorización con agente se instala/invoca un componente confiable (agente) en la página web del servidor a monitorizar. Este agente (que se cargará en el navegador del usuario) se encargará de supervisar en tiempo real cualquier cambio que sea realizado en los componentes cargados de las páginas monitorizadas y analizar su comportamiento, pudiendo actuar de forma detectiva ante acciones no autorizadas (client-side monitoring).
| Ventajas | Desventajas |
|---|---|
| El despliegue de agentes es sencillo, realizado a través de invocaciones JavaScript. | La integración suele implicar el despliegue de líneas de código adicionales en los sitios web a proteger. |
| Dependiendo de la solución, se puede monitorizar también los encabezados HTTP. | Dependiendo de la solución, el agente solo podrá informar de los resultados de la monitorización, sin la capacidad de «bloquear» el contenido malicioso. |
| Monitoriza el comportamiento de cada script durante su ejecución. | Este tipo de soluciones suelen tener muchos falsos positivos y requiere de afinamiento manual. |
Ejemplos de soluciones que implementan este enfoque:
- JScrambler: https://jscrambler.com
- SourceDefense: https://sourcedefense.com/
- Feroot: https://www.feroot.com
- Human Security: https://www.humansecurity.com
Opción 4: Uso de proxies
A diferencia de las soluciones anteriores, las soluciones basadas en proxies suelen interceptar el tráfico entre el servidor web y el navegador del usuario, revisando el contenido transmitido y detectando cualquier tipo de cambio ANTES de que el contenido sea distribuido al usuario final. Algunas de estas soluciones se integran con plataformas de redes de distribución de contenido (Content Delivery Network – CDN) de tal manera que puede tener el control total sobre los flujos del tráfico, pudiendo bloquear el contenido malicioso ANTES de que sea distribuido al cliente final.
| Ventajas | Desventajas |
|---|---|
| No requiere instalación ni modificaciones en el servidor web a proteger | Este tipo de soluciones suelen apoyarse en políticas CSP/SRI, por lo que es necesario que el administrador de la solución conozca el funcionamiento de estas especificaciones. |
| Se integra con otras herramientas como módulos de WAF, detección antimalware, soluciones de caché, etc. | Necesita tareas de afinamiento. |
| Si su despliegue está vinculado a un CDN, se añade una capa extra de disponibilidad. | No protege interfaces o secciones del sitio web que no estén detrás del servicio de proxy. |
Ejemplos de soluciones que implementan este enfoque:
- Akamai Client-Side Protection & Compliance: https://www.akamai.com/es/products/client-side-protection-compliance
- Cloudflare PayShield: https://www.cloudflare.com/en-gb/application-services/products/page-shield/
- Imperva Client-Side Protection: https://www.imperva.com/products/client-side-protection-csp/
- c/side: https://cside.dev/
Conclusión
Con los ataques de e-skimming/formjacking al alza, es imprescindible que los sitios de comercio electrónico que capturan datos de tarjetas desplieguen controles detectivos y reactivos orientados hacia la detección de código activo malicioso (JavaScript principalmente) que se pueda cargar en el navegador del usuario final. Estos controles deben validar la integridad de los scripts y los encabezados HTTP autorizados y denegar/reportar cualquier comportamiento sospechoso.
Dependiendo de la complejidad del sitios web de comercio electrónico a proteger, la cantidad de tráfico a ser analizado, la periodicidad en la que estas validaciones deben ser realizadas y la carga adicional en el desempeño de la página web, las entidades pueden elegir entre varias opciones de implementación para lograr el cumplimiento con los controles 6.4.3 y 11.6.1 de PCI DSS v4.0, que entran en vigor a partir del 1 de abril de 2025.
ES 
EN